Server-based network architectures—unlike conventional file servers or client/server architectures—can be identified in that applications are not run locally on end devices, but centrally on a server. Solely the presentation occurs on the local end device. Besides screen presentation exists the presentation form of the printout, which can also be executed on the local end device. Thus print jobs in server-based architectures can be printed over locally connected print devices or network print devices, which in turn can also be configured as locally networked or as networked remote devices, whereby creation of the print job is always executed on the server.
Creation of a print job in named networks based on MS Windows operating systems always occurs in three phases, which are completed on the server:    1. Application-specific creation of page representation, with which the print job is converted to an EMF (enhanced Metafile) file format.    2. Onscreen preview option using the EMF file of the page which is later to be printed.    3. Printer-specific preparation (rendering) in which the EMF file is converted to a RAW file using a device-specific printer driver.
The rendered print job is finally sent to the end device and there printed out.
Different problems arise during print job rendering [processing] in server-based networks. All printer devices available on the client side must, for example, be supported; in other words, a relevant printer driver must be installed on the server for every print device. A multiplicity of printer drivers leads to conflicts.
No driver exists for terminal servers (NT or 2000) for print devices, which communicate bi-directionally, so that these cannot be used in server-based networks.
For the user of an end device, independent installation of a local print device is as a rule only possible if the driver for the print device is already available on the server, thereby supporting the installation.
To avoid such problems, it is known to install a .pdf writer as default printer on the server. Print jobs from any application are converted into an EMF file as usual, and then given to the .pdf writer. This application creates a .pdf document, which is sent to the end device. On the end device, this data format can be viewed using a .pdf viewer or forwarded with help from the installed printer driver to a port and/or print device for printout.
Although this process indeed avoids printer driver conflicts, it nevertheless causes other disadvantages, which could outweigh the intended advantage. A loss of quality is generally unavoidable when diverting the data over the .pdf writer, so that this process is excluded for some applications. Furthermore, dedicated print servers and network printers are not supported by this method. There is no streaming, i.e. transmission of the file to be printed in smaller packets, so that printing the file requires much time. To use this method, each end device requires an Acrobat Reader, which further decreases the already low capacity of the end devices in such network architectures. Ultimately, this method causes a high consumption of both server and client CPU resources.